Comportamiento
Los mensajes navegan por los enlaces, a priori en ambas direcciones
Estado y comportamiento están relacionados
Ejemplo: no es posible aterrizar un avión si no está volando. Está volando como consecuencia de haber despegado del suelo
Persistencia
La persistencia de los objetos designa la capacidad de un objeto trascender en el espacio/tiempo
Podremos después reconstruirlo, es decir, cogerlo de memoria secundaria para utilizarlo en la ejecución (materialización del objeto)
Los lenguajes OO no proponen soporte adecuado para la persistencia, la cual debería ser transparente, un objeto existe desde su creación hasta que se destruya
Comunicación
Un sistema informático puede verse como un conjunto de objetos autónomos y concurrentes que trabajan de manera coordinada en la consecución de un fin específico
El comportamiento global se basa pues en la comunicación entre los objetos que la componen
Comunicación
Categorías de objetos:
Activos – Pasivos
Cliente – Servidores, Agentes
Objeto Activo: posee un hilo de ejecución (thread) propio y puede iniciar una actividad
Objeto Pasivo: no puede iniciar una actividad pero puede enviar estímulos una vez que se le solicita un servicio
Cliente es el objeto que solicita un servicio. Servidor es el objeto que provee el servicio solicitado
Comunicación
Los agentes reúnen las características de clientes y servidores
Son la base del mecanismo de delegación
Introducen indirección: un cliente puede comunicarse con un servidor que no conoce directamente
Comunicación
Ejemplo en el que un agente hace de aislante:
Un agente
Un cliente
Sevidor 1
Servidor 2
El Concepto de Mensaje
La unidad de comunicación entre objetos se llama mensaje
El mensaje es el soporte de una comunicación que vincula dinámicamente los objetos que fueron separados previamente en el proceso de descomposición
Adquiere toda su fuerza cuando se asocia al polimorfismo y al enlace dinámico
El Concepto de Mensaje
Objeto 4
Objeto 3
Objeto 2
Objeto 1
: Mensaje E
: Mensaje D
: Mensaje C
: Mensaje A
Mensaje y Estímulo
Un estímulo causará la invocación de una operación, la creación o destrucción de un objeto o la aparición de una señal
Un mensaje es la especificación de un estímulo
Tipos de flujo de control:
Llamada a procedimiento o flujo de control anidado
Flujo de control plano
Retorno de una llamada a procedimiento
Otras variaciones
Esperado (balking)
Cronometrado (time-out)
Casos de Uso
Los Casos de Uso (Ivar Jacobson) describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el p.d.v. del usuario
Permiten definir los límites del sistema y las relaciones entre el sistema y el entorno
Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de la implementación
Comparación con respecto a los Diagramas de Flujo de Datos del Enfoque Estructurado
Casos de Uso
Los Casos de Uso cubren la carencia existente en métodos previos (OMT, Booch) en cuanto a la determinación de requisitos
Los Casos de Uso particionan el conjunto de necesidades atendiendo a la categoría de usuarios que participan en el mismo
Están basado en el lenguaje natural, es decir, es accesible por los usuarios
Casos de Uso
Ejemplo:
Casos de Uso
Actores:
Principales: personas que usan el sistema
Secundarios: personas que mantienen o administran el sistema
Material externo: dispositivos materiales imprescindibles que forman parte del ámbito de la aplicación y deben ser utilizados
Otros sistemas: sistemas con los que el sistema interactúa
La misma persona física puede interpretar varios papeles como actores distintos
El nombre del actor describe el papel desempeñado
Casos de Uso
Los Casos de Uso se determinan observando y precisando, actor por actor, las secuencias de interacción, los escenarios, desde el punto de vista del usuario
Un escenario es una instancia de un caso de uso
Los casos de uso intervienen durante todo el ciclo de vida. El proceso de desarrollo estará dirigido por los casos de uso
Casos de Uso: Relaciones
UML define cuatro tipos de relación en los Diagramas de Casos de Uso:
Comunicación
Casos de Uso: Relaciones
Inclusión : una instancia del Caso de Uso origen incluye también el comportamiento descrito por el Caso de Uso destino
<> reemplazó al denominado <>
Casos de Uso: Relaciones
Extensión : el Caso de Uso origen extiende el comportamiento del Caso de Uso destino
Casos de Uso: Relaciones
Herencia : el Caso de Uso origen hereda la especificación del Caso de Uso destino y posiblemente la modifica y/o amplía
Casos de Uso: Relaciones
Ejemplo:
Casos de Uso: Relaciones
Ejemplo:
Casos de Uso: Construcción
Un caso de uso debe ser simple, inteligible, claro y conciso
Generalmente hay pocos actores asociados a cada Caso de Uso
Preguntas clave:
¿cuáles son las tareas del actor?
¿qué información crea, guarda, modifica, destruye o lee el actor?
¿debe el actor notificar al sistema los cambios externos?
¿debe el sistema informar al actor de los cambios internos?
Casos de Uso: Construcción
La descripción del Caso de Uso comprende:
el inicio: cuándo y qué actor lo produce?
el fin: cuándo se produce y qué valor devuelve?
la interacción actor-caso de uso: qué mensajes intercambian ambos?
objetivo del caso de uso: ¿qué lleva a cabo o intenta?
cronología y origen de las interacciones
repeticiones de comportamiento: ¿qué operaciones son iteradas?
situaciones opcionales: ¿qué ejecuciones alternativas se presentan en el caso de uso?
Modelo de Casos de Uso y Modelo Conceptual (Análisis)
La especificación de cada caso de uso y los correspondientes D. de Interacción establecen el vínculo con el modelo conceptual
En métodos OO que carecen de una técnica de captura de requisitos se comienza inmediatamente con la construcción del modelo conceptual (análisis)
 Página anterior | Volver al principio del trabajo | Página siguiente  |